home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 48 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.3 KB
  1. From: James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de>
  2. Message-ID: <9601161735.AA02375@lts.sel.alcatel.de>
  3. X-Original-Date: Tue, 16 Jan 96 18:35:47 +0100
  4. Path: in1.uu.net!bounce-back
  5. Date: 16 Jan 96 18:32:36 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. In-Reply-To: thp@cs.ucr.edu's message of 16 Jan 96 10:35:45 GMT
  8. Newsgroups: comp.std.c++
  9. Subject: Re: Throwing an exception from within a signal handler
  10. References: <4cpmh0$ltf@natasha.rmii.com> <Etay_Bogner-0901961008510001@metay.stil.scitex.com> <9601003.29971@mulga.cs.mu.OZ.AU> <4dekiv$22h@galaxy.ucr.edu>
  11. Organization: GABI Software, Sarl.
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMPvvUeEDnX0m9pzZAQG4LwF/ZDokznYtkY31RxpFsPXWtR0xUxqL+mih
  14.     dGlvDiKwVcZjK9JUFrdgW027U55QZiTX
  15.     =MLZh
  16.  
  17. In article <4dekiv$22h@galaxy.ucr.edu> thp@cs.ucr.edu (Tom Payne)
  18. writes:
  19.  
  20. |> Implicit in a qestion of what the Standard says are the related
  21. |> questions of what it should say and why --- why shouldn't signal
  22. |> handlers be allowed to throw exceptions?  (The question seems both
  23. |> interesting and appropriate.)
  24.  
  25. Because of the problems related to atomicity which crop up when
  26. asynchronous events are considered.
  27.  
  28. From an implementation point of view, it would introduce a number of
  29. constraints, which could possibly have a negative effect on
  30. performance.  Handling an exception involves unwinding the stack,
  31. which in turn involves exploiting a known stack structure.  On
  32. entering a function, the compiler typically generates code to set up a
  33. new stack frame.  At present, there is no requirement that this code
  34. be `atomic' in any way; allow an asynchronous exception, and extra
  35. precautions must be taken.
  36.  
  37. From a user point of view, asynchronous exceptions introduce severe
  38. constraints on the types that can be thrown.  Basically, because of
  39. the constraints concerning atomicity, the C standard greatly restrains
  40. what an implementation may do in a signal handler; these restraints
  41. would in turn so limit the types you can throw as to make them
  42. useless.  Basically, even if the implementation problems above were
  43. considered acceptable cost, the best the standard could do is
  44. guarantee that you could throw a sig_atomic_t.
  45.  
  46. Potentially, I suppose, the standard could make more guarantees
  47. concerning synchronous signals (those raised by `abort' or `raise');
  48. in fact, the C standard does.  Is it worth it?
  49.  
  50. There is one practical case that might be worth discussing: SIGFPE.  I
  51. don't think that the standard can make too many guarantees about this
  52. one, since on some hardware, it is asynchronous.  But on many
  53. implementations, it is synchronous, or close enough to being
  54. synchronous, so that you could throw an exception from it.  It would
  55. be nice, as a quality of implementation issue, if such implementations
  56. actually documented this fact, and the fact that you could count on
  57. it.
  58.  
  59. --
  60. James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
  61. GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
  62. Conseils, itudes et rialisations en logiciel orienti objet --
  63.                 -- A la recherche d'une activiti dans une region francophone
  64. ---
  65. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  66.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  67.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  68.